This article is a modified introduction to the book The easiest way to learn design patterns. The book is available in digital format at LeanPub and in either Kindle-specific format or in print from Amazon.
Design patterns are something that you will need to get familiar with as a programmer who works with object-oriented languages. This is primarily because they represent well-defined solutions to common software development problems. So, instead of thinking through all the details of your solution, you can simply check if any of the existing design patterns can be used. You won’t have to reinvent the wheel.
As a software developer, you would be familiar with reusable software components, such as methods, functions, public classes, libraries, etc. Well, you can think of design patterns as reusable solutions to common software problems. If you are familiar with which design patterns can solve a specific type of problem, you will no longer have to come up with a bespoke solution, which could have taken you a significant amount of time to design and implement. All you’ll have to do is just pick the most suitable design pattern and apply it in a specific way to solve this specific problem. The solution is already there. The time taken to implement it would not be much greater than the time it takes you to type the code in.
If you are new to design patterns, let’s go through a quick overview of what they are.
What design patterns are
Design patterns are prescribed ways of implementing solutions to common problems. While every specific implementation of them will be bespoke and only relevant to a specific codebase, they still determine how your code should be structured. A design pattern would tell you how different object types in your code should interact with one another. Specific objects would have specific roles, which are prescribed by a specific design pattern. However, a specific implementation of those objects would still be relevant only to a specific problem.
If you will, you can compare the concept of design patterns with Agile principles. For example, if you follow Scrum, you will go through all of the relevant ceremonies (daily standups, sprint reviews, etc.). You would have specific roles (Scrum master, product owner, and Scrum team members). You would work in sprints of a specific length. However, the problems that you will be solving during your sprints will be very specific to your organization. The actual implementation of the Scrum methodology will be bespoke.
Design patterns have been used in object-oriented programming for some time. But in 1994, they were officially classified and described in a book called Design Patterns: Elements of Reusable Object-Oriented Software, which was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, who are collectively known as The Gang of Four.
So, in a nutshell, each design pattern prescribes how the objects in your code should be structured and how they should behave. For solutions where multiple objects are involved, it prescribes the role for each object.
Let’s have a look at a design pattern called Strategy as our example. This pattern is commonly used to make your code easily maintainable and testable in situations where you have complex conditional logic. In this design pattern, you have a class with the role of Strategy. This class stores an interface, which has the role of Context. There are several classes that implement this interface, each performing a specific behavior. Then, all you do inside your conditional logic is assign a specific Context implementation to the Strategy. And then, once all conditions have been examined, you just execute some method on the Context object which the Strategy class encapsulates. This will execute the behavior that was specific to a particular condition, as a specific implementation of Context was assigned to Strategy when a specific condition was hit.
So, the design patterns prescribe roles to objects and how these objects should interact with one another. We have one object with the role of Strategy and several implementations of an object with the role of Context. But what the design pattern doesn’t prescribe is what specific behavior should the implementation perform or what data type(s) should it return, if any. It’s up to us to decide.
Some design patterns don’t even involve multiple objects with different roles. Singleton and Prototype patterns, for example, prescribe how to apply internal logic to an object and what public members should this object have for other objects to access.
So, why would you use design patterns? Why just not provide a bespoke solution to every problem you face? Well, there are some good reasons why design patterns are better. But the reasons why you would want to learn them go beyond the fact that design patterns merely provide a better solution.
Why would you want to learn design patterns?
Design patterns will indeed make you more effective at solving problems. When you have used them for a while, you will intuitively know where to apply them. So, you will not have to spend much time thinking of the solution. You will be able to apply one right away.
Not only will you be able to solve the problem quicker, but your code will be cleaner. It will be more readable, easier to test, and easier to maintain.
Let’s go back to our example of Strategy pattern. You can, of course, just use complex conditional logic in a single method of your code. But then imagine how hard it might be to test the logic. Also, if the logic is complex, it might not necessarily be the most readable code.
When the Strategy pattern is implemented, it solves the problem. But beyond this, it makes your code clean. The original method that contains the conditional logic only selects which Strategy to implement. It doesn’t do anything beyond that. Easy to read. Easy to test. Each Strategy implementation only contains an atomic piece of logic that is responsible for only one action. Easy to read. Easy to test.
However, the benefits of knowing design patterns go beyond them being good solutions to common problems. Many reputable organizations ask questions about them during job interviews. The major IT giants almost certainly do. So, not knowing design patterns might prevent you from getting a job in the company of your dreams.
The main problem with design patterns is that they are not necessarily easy to learn. Let’s examine why that is.
Why design patterns are hard to learn
Many developers, especially the ones who don’t have a lot of software-building experience, struggle with design patterns. But if you do struggle with them, it may prevent you from getting a programming job at a reputable organization. After all, recruiting managers often ask questions about design patterns. Otherwise, not knowing design patterns will make you less effective as a software developer, which will slow down your career progress.
The main reason why design patterns are so hard to learn is because of the way they are normally taught. Usually, if you pick pretty much any book on design patterns or open pretty much any online article about them, it would provide a collection of design patterns that you would need to go through. You would then have to go through each of them, try your best to understand the principles behind it, and only then try to figure out how to apply it in a real-life situation.
It’s a tedious process that doesn’t always bring about the right results. It’s not uncommon for software developers to memorize just a handful of design patterns that they have been using in their own projects. The remaining ones have been forgotten as soon as they’ve been learned. And it’s hard to figure out which design pattern applies in which situation if you only remember a handful of them.
Helping you to learn design patterns easily
I understand how hard are design patterns to learn because I myself, at one point, struggled to learn them. When I finally managed to understand them, I could also see how the whole process would have been much easier only if I had taught the design patterns differently. This is what inspired me to write a book that I called “The easiest way to learn design patterns”.
Sounds like I wasn’t wrong about my methodology, as this book became popular, I received a lot of positive feedback from its readers, and it repeatedly made it into the number one bestseller spot on LeanPub.
This book provides a different approach. It uses a methodology that makes it easy to learn design patterns. So, you no longer have to brute-force your way through them. The process of effective learning is not about memorization. It’s about associations. You learn new things easily when you can clearly see how new facts relate to your existing knowledge. And this is precisely the method that this book is built around.
You won’t have to brute-force your way into design patterns. In fact, you won’t even start with the design patterns. First, we will go through a list of common problems that software developers are required to solve. Those are the things that every software developer can associate with. Even if you haven’t faced a particular type of problem yet, you will still be able to easily understand its description. For each of these problems, we will go through the design patterns that can solve it. For each one of them, you will go through its core principle and the description of how it can solve this type of problem. Only then you will be invited to examine this particular design pattern in detail, so you can understand how to implement it in your own code.
This structure of the book also makes it valuable as a reference book. Even when you don’t know or don’t remember design patterns, looking them up becomes easy. What you need to find is a description of the type of problem you are trying to solve. And then you will be able to follow it to find the actual design patterns that you can apply to solve it.
Therefore this book is not only an effective learning tool. It’s also a reference book that’s incredibly easy to navigate. It’s been structured in such a way that you’ll be able to find the right answer in seconds.
One important thing to note is that this book doesn’t aim to cover absolutely all design patterns that exist out there. It focuses on the classic design patterns that were outlined by The Gang of Four. So some of the design patterns that you have heard of might be missing.
However, these classic design patterns formed the foundation for all design patterns that came after. Therefore, if you get familiar with them, you will have no trouble learning any newer patterns.
The structure of this book
This book consists of three parts. It has been structured to facilitate easy learning of design patterns for those who aren’t familiar with them.
Part 1: SOLID principles and why they are important
SOLID principles are the most fundamental rules of clean code in object-oriented programming. And all design patterns depend on these principles. This is why, in order to be able to understand design patterns, you need to be familiar with SOLID principles. This is why this is the very first thing that you will learn in this book.
Part 2: The problems that design patterns are intended to solve
This part lists various problem types that software developers commonly face. For each of these problems, it provides a list of design patterns that can solve it.
This part of the book doesn’t provide an in-depth description of each of the patterns. It merely provides a brief overview of what each design pattern does and how it can solve a specific type of problem.
This part of the book has been structured in such a way as to ensure that those developers who aren’t yet familiar with design patterns can easily look them up and be able to quickly find the most suitable design pattern for a specific type of problem they are facing.
Part 3: Design patterns demonstrated in C#
The final part of the book breaks down each of the design patterns in depth. It uses C# code samples to demonstrate how you can implement each of the patterns in your own code.
Getting in touch with the author
If you want to get in touch with me regarding the content of the book, you can contact me via either Twitter or LinkedIn. Perhaps, there is additional content that you want to have included in the next edition of the book. Or maybe you found some errors in the current edition. Any feedback is welcome. And this is how you can get in touch:
Twitter: https://twitter.com/FSazanavets
LinkedIn: https://www.linkedin.com/in/fiodar-sazanavets/
Helping to spread the word
If you found this book useful, please write a review about it. This will help the author and will help the algorithms to show this book to more people who might need help with learning design patterns.
And, of course, if you liked this book, spread the word. Let your friends know about it. This way, you will help more people become better software developers.
